Efficient retrieval of 4g lte capabilities

ABSTRACT

A mobile device executes a background process under an on demand model that queries a remote service exposed by a mobile broadband network to receive status updates as to the capabilities of devices, such as the ability to stream video, that are associated with contacts that are stored on the mobile device. When a mobile device user invokes an action like using a dialer application that causes a contact to be displayed on the device&#39;s user interface (UI) such as in a contact card or contact list format, the background process immediately retrieves status for that contact card or list. While waiting for the status retrieval to complete, the background process will trigger the display of a temporary UI on the mobile device which can show either unknown capabilities status or show the most recently retrieved status that is read out of a cache.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. application Ser. No.14/221,773 filed Mar. 21, 2014, entitled, “EFFICIENT RETRIEVAL OF 4G LTECAPABILITIES”, which is incorporated herein by reference in itsentirety.

BACKGROUND

Mobile devices are leveraging new communication services on advancedmobile operator (MO) networks that provide broadband services to supportrich user experiences such as video messaging and video calling. Suchnetworks may include, for example, 4G LTE (Fourth Generation, Long TermEvolution) systems as described by the 3GPP (Third GenerationPartnership Project) as an evolution of the GSM/UMTS (Global System forMobile communication/Universal Mobile Telecommunications System)standards. While such advanced mobile broadband networks performsatisfactorily in many applications, further improvements are desired toenable additional features and improved experiences for mobile deviceusers.

This Background is provided to introduce a brief context for the Summaryand Detailed Description that follow. This Background is not intended tobe an aid in determining the scope of the claimed subject matter nor beviewed as limiting the claimed subject matter to implementations thatsolve any or all of the disadvantages or problems presented above.

SUMMARY

A mobile device executes a background process under an on demand modelthat queries a remote service exposed by a mobile broadband network,such as a 4G LTE network, to receive status updates as to thecapabilities of devices that are associated with contacts that arestored on the mobile device. Such capabilities can include theavailability of a contact's device to support streaming video, forexample, as part of video messaging and video calling features. When amobile device user invokes an action like using a dialer applicationthat causes a contact to be displayed on the device's user interface(UI) such as in a contact card or contact list format, the backgroundprocess immediately retrieves status for that contact card or list.While waiting for the status retrieval to complete, the backgroundprocess will trigger the display of a temporary UI on the mobile devicewhich can show either unknown capabilities status or show the mostrecently retrieved status that is read out of a cache.

Advantageously, the retrieval of capabilities status under the on demandmodel enables resource costs to be incurred that are more proportionalto the number of contacts that a user is actually going to access.Compared with other techniques such as proactively querying the serviceon a periodic basis and pulling down current status for all of thecontacts just in case it is needed, the present capability retrieval canreactively obtain status from the service on demand when the useraccesses a contact card or a contact list. Thus, the UI provides up todate status for contact cards and lists viewed by the user on the mobiledevice while minimizing the use of resources such as battery life.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter. Furthermore, the claimed subject matter is not limited toimplementations that solve any or all disadvantages noted in any part ofthis disclosure. It will be appreciated that the above-described subjectmatter may be implemented as a computer-controlled apparatus, a computerprocess, a computing system, or as an article of manufacture such as oneor more computer-readable storage media. These and various otherfeatures will be apparent from a reading of the following DetailedDescription and a review of the associated drawings.

DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an illustrative telecommunications environment in whichdevices having telephony capabilities communicate over a mobilebroadband network;

FIGS. 2 and 3 show various features that may be supported on differentmobile devices;

FIG. 4 depicts illustrative contact lists and contact cards that may bestored and displayed on a mobile device;

FIGS. 5 and 6 depict illustrative user interfaces for two differentcontact cards;

FIG. 7 shows an illustrative background process for status retrievalusing an on demand model for status retrieval;

FIG. 8 shows illustrative details of a request for status under the ondemand model;

FIG. 9 shows illustrative details of a status response under the ondemand model;

FIG. 10 shows application of heuristics to RCS (Rich CommunicationServices) availability information;

FIG. 11 shows an illustrative taxonomy of options that may beimplemented under the on demand model;

FIG. 12 is a flowchart of an illustrative method that implements aminimal option under the on demand model;

FIG. 13 is a flowchart of an illustrative method that implements a basiccaching option under the on demand model;

FIG. 14 is a flowchart of an illustrative method that implements acaching with timestamp option under the on demand model;

FIG. 15 is a flowchart of an illustrative method that implements aretrieval in lists option under the on demand model;

FIGS. 16 and 17 show illustrative UIs that show contacts presented inlists;

FIGS. 18 and 19 show illustrative UIs in which video functionality isrespectively enabled and disabled;

FIG. 20 shows an illustrative taxonomy of criteria that may be appliedto retrieve additional screens of contact status;

FIGS. 21 and 22 show public application programming interfaces (APIs)that may be exposed by a service for facilitating status retrieval underthe on demand model;

FIG. 23 is a simplified block diagram of an illustrative computer systemsuch as a personal computer (PC) that may be used in part to implementthe present video capabilities retrieval;

FIG. 24 shows a block diagram of an illustrative device that may be usedin part to implement the present video capabilities retrieval; and

FIG. 25 is a block diagram of an illustrative mobile device.

Like reference numerals indicate like elements in the drawings. Elementsare not drawn to scale unless otherwise indicated.

DETAILED DESCRIPTION

FIG. 1 shows an illustrative telecommunications environment 100 in whichvarious users 105 employ respective devices 110 that communicate over amobile broadband network 115. The devices 110 provide voice telephonycapabilities and typically support data-consuming applications such asInternet browsing and multimedia (e.g., music, video, etc.) consumptionin addition to various other features. The devices 110 may include, forexample, user equipment, mobile phones, cell phones, and smartphoneswhich users often employ to make and receive voice and/or multimediacalls.

However, alternative types of electronic devices are also envisioned tobe usable within the telecommunications environment 100 so long as theyare configured with telephony capabilities and can connect to the mobilebroadband network 115, as described in more detail below. Suchalternative devices variously include handheld computing devices, PDAs(Personal Digital Assistants), portable media players, wearablecomputers, navigation devices such as GPS (Global Positioning System)systems, laptop PCs (personal computers) desktop computers, multimediaconsoles, gaming systems, or the like. In the discussion that follows,the use of the term “mobile device” is intended to cover all devicesthat are configured with telephony capabilities and are capable ofwireless connectivity to the mobile broadband network 115.

Each mobile device 110 will typically have a prearranged associationwith the mobile broadband network 115. For example, a user 105 willtypically be a subscriber to a cellular service plan so that the user'smobile device 110 can access the mobile broadband network as valid andauthenticated user equipment. The mobile broadband network 115 in thisillustrative example is configured as a 4G LTE network which includes aradio access network 120 having a number of macrocells that supportaccess by the devices 110 to a mobile operator (MO) core network 125.The backend of the mobile broadband network 115 typically includesinterfaces that support a connection to network infrastructure includinga public switched telephone network (PSTN) 130 so that communication isenabled between the mobile device 110 and conventional wireline userequipment 135. A connection to the Internet 140 is also typicallysupported so that the mobile devices 110 can access content provided byone or more external content providers 145. A network element 150 islocated in the MO core network 125 which exposes a service 155 that maybe configured to provide status regarding particular capabilities of thedevices 110 as described in more detail below.

The various mobile devices 110 and wireline equipment 135 in thetelecommunications environment 100 can support different features,functionalities, and capabilities (here referred to generally as“features”). For example, various types of equipment support their ownfeature set, as indicated by respective reference numerals 205, 210, and215 in FIG. 2. As shown in FIG. 3, some of the features supported on agiven device can be similar to those supported on others, while otherfeatures may be unique to a given device. The degree of overlap and/ordistinctiveness among features supported on the various mobile devices110 can vary by implementation. For example, some devices 110 cansupport touch controls, gesture recognition, and voice commands, whileothers may enable a more limited user interface (UI). Some devices maysupport video consumption and Internet browsing, while other devices maysupport more limited media handling and network interface features.

Some features may not be available on a device because of technicalreasons. For example, a mobile device might include support for voicecalling but is not equipped to handle video due to technical reasonssuch as various hardware, software, and/or firmware constraints that areimposed by design. In other situations, a given feature may be capableof support by the technology in the mobile device, but the features aredisabled for non-technical reasons such as personal preference,business, and/or policy reasons. For example, a user 105 may wish todisable video handling and streaming to a mobile device so as to reducethe expense for data access that is part of a subscription package to MOservices. Or, an enterprise or business may wish to restrict executionof some applications or limit access to some external content providersfor its corporate users.

Features may also be subject to availability based on temporal and/orenvironment conditions. For example, a user 105 may wish to consume astreaming video on a mobile device 110 that can normally handle videobut the device is near the monthly data cap that is part of the user'ssubscription. Or, the user may be on a train that is going through atunnel and has no cellular access or be in an area that supports onlyvoice calling but not data access on the mobile broadband network 115.

One particular example of a feature supported on a mobile device isshown in FIG. 4 in which information about contacts are stored. Asshown, a given mobile device 110 may organize the stored informationusing one or more contact lists 405 that represent information about thegroup of contacts 410. Some of the contacts 410 may be subscribers tothe mobile broadband network 115, while other contacts 410 can besubscribers or otherwise associated with other networks (e.g., othertelephony networks, mobile networks, PSTNs, etc.). Each contact list 405typically comprises a collection of contact cards where each card 415 isused to store information about a particular user (or institution,organization, business, etc.) such as contact name and picture,telephone numbers for mobile, work, home, etc., personal and work emailaddresses, home and office addresses, websites, significant other's andchildren's names, birthdays, and the like.

FIG. 5 depicts an illustrative example of a contact card 500 as may beshown on a display 505 of a mobile device 110. It is emphasized that thecontact cards shown and described here, and their layout and designs areintended to be illustrative and that variations in how a contact card ispresented, the information it contains, and the ways the user caninteract with a contact card can vary from that shown and described inaccordance with the needs of a particular implementation of videocapability retrieval.

In this example various information about a contact named “ThomasHoward” is provided on a UI supported on the display screen. The user105 (not shown) can interact with the UI here by touching the screen atappropriate locations to launch various actions from the contact card500 such as placing a call to a contact's mobile phone, sending him atext or email, etc. Additional information can typically be revealed byusing the touchscreen to scroll (e.g., up/down, side-to-side) to otherplaces on the contact card 500. Thus, the contact card 500 may containcollective information about the contact that is more extensive that canbe shown at one time on a single UI screen. The additional informationthat is available but not currently displayed is organized into virtualscreens or pages (collectively referred to here as “screens”), whereeach screen can be loaded for display on the UI in response to theuser's scrolling actions. It is emphasized that the particular scrollingUI with accessible virtual screens shown in the example herein and theuser interaction therewith is intended be illustrative and that other UIdesigns and behaviors may be utilized to meet the needs of a particularimplementation of the present video capability retrieval.

As shown in FIG. 5 and in enlarged view, a glyph 510 is displayed nearthe contact's photo to indicate to the user that the contact isassociated with a mobile device that currently supports broadband videocapability over the mobile broadband network 115 (FIG. 1). In addition,certain features are enabled on the contact card 500 including sending avideo message, indicated by reference numeral 515, and making a videocall to the contact's mobile number, indicated by reference numeral 520.The video message is shown as using the emerging RCS (Rich CommunicationService) which is a service offering supported by the MO in this examplethat has similarity to conventional SMS (Short Message Service) and MMS(Multimedia Message Service) services which are typically andubiquitously supported today.

In comparison to the contact card 500 shown in FIG. 5, the contact card600 shown in FIG. 6 for a contact named “Peter Yanovich” does notdisplay the video glyph nor does its UI enable video features such asvideo-based messaging and calling. Thus, in this example, the contactcard 600 indicates to the user 105 that the contact currently is notable to reached and communicated using video features. As describedabove, there could be various reasons for the limited availability ofvideo features for that particular contact. For example, the contact maynot have a video-capable mobile device, has chosen not to enable videofeatures, is not presently in an area of network coverage that supportsbroadband data access, or the like.

The status as to the availability of features on each of the mobiledevices in the user's contacts 410 (FIG. 4) may be obtained in variousways. For example, a given mobile device 110 may query the service 155in the MO's mobile broadband network 115 on a periodic basis to requeststatus as to feature support and capabilities (collectively referred tohere as “status”), including video capability, for each deviceassociated with each contact. While such periodic background bulkretrieval enables the UI on the device 110 to show a cached status thatis current as of the last status update, battery drain increases asretrieval frequency increases, as as does the impact on other mobiledevice resources such as processing cycles and memory utilization.Battery drain is also likely to occur at higher than direct proportionto status retrieval frequency due to overhead cost of initializing andoperating the mobile device's radio. However, staleness of statusincreases as frequency decreases, and at some average level of stalenessperforming the periodic background bulk status retrieval is no longerworthwhile.

A supplementary solution to periodic bulk retrieval is to initiate animmediate retrieval of a single instance of status when the user opens aparticular contact card on the device's UI. The UI in this case caninitially reflect cached status from the most recent periodic backgroundbulk retrieval, but then can be quickly refreshed to show current statusfrom the initiated single instance retrieval. Battery drain versusstaleness could potentially be balanced by tuning the frequency ofperiodic bulk status retrieval.

Unfortunately, for many users it can be expected that bulk retrievalwith or without immediate retrieval of status can still be less thanoptimally performant in many scenarios. For example, if the bulkretrieval frequency is once every 60 minutes, and a user visits thecontact cards only 10 times per month, the mobile device will still do720 periodic background bulk retrievals covering everyone in the user'sgroup of contacts. In addition, it has been observed that the morecontacts a user has the less likely it is for a given number's status tobe needed. In some cases users have 2,000 or more contacts. Thepopularity of social networking systems and other online resources makesit quite easy to have a large contact list, but it is unlikely thatusers regularly interact with most of their contacts. Thus, the resourcecosts in retrieving status using the solutions described above can beprohibitive.

The present video capability retrieval enables resource costs to beincurred that are more proportional to the number of contacts that auser is actually going to access. Instead of proactively querying theservice on a periodic basis and pulling down current status for all ofthe contacts just in case it is needed, the present video capabilityretrieval can reactively obtain status from the service on demand whenthe user accesses a contact card or a contact list.

An on demand model 700 is utilized as shown in FIG. 7. In summary, theon demand model 700 is implemented on a mobile device 110 so that whenthe user accesses a contact card or a contact list, status 705 isretrieved from the service 155 in response to a request 710 using abackground process 715 or thread that is implemented by functionalitythat is provided, for example, by an application or operating systemthat executes on the mobile device.

When a contact list is accessed by the user and displayed, the on demandmodel calls for status to be retrieved for additional contacts invirtual pages or screens beyond those contacts that are currentlydisplayed on the UI. That way, some status data is pre-fetched in caseit is needed to be displayed for the user or is given prioritization forretrieval over other data (here, pre-fetched and prioritized status datais commonly referred to as “pre-fetched status”). The pre-fetched statusin accordance with the on demand model is contextually related with thecontacts that are currently being accessed by the user, as described inmore detail below. The use of such contextual relationship enables thepre-fetched status under the on demand model to have greater potentialrelevance to the user while reducing the amount of retrieval of lessrelevant data (and accordingly reducing the load on resources). The ondemand model thus stands in contrast with the aforementioned bulkretrieval technique where large amounts of data may be retrievedirrespective of its likelihood that it is actually accessed by the user.

As shown in FIG. 8, the request 710 for status can comprise a singlenumber 805 or a batch of numbers 810. The term “number” here typicallyrefers to the telephone number that is uniquely associated with a mobiledevice or other device having telephony capabilities. For example, thenumber may comprise the 10 digit string including area code in theUnited States or comprise the MSISDN (Mobile Subscriber IntegratedServices Digital Network) or IMSI (International Mobile SubscriberIdentity) in some cases. As shown in FIG. 9, the status 705 sent by theservice 155 as a response to the request 710 includes current RCSavailability 905 per number. Additional information per number, such ascapabilities of a mobile device other than RCS, can also be included inthe status 705 in some implementations, as indicated by referencenumeral 910. In some cases, the service may optionally provide atimestamp 915 in the status 705. Alternatively, the mobile device 110and/or the background process 715 may apply its own timestamp when thestatus is received.

The current RCS availability 905 reported by the service 155 in thestatus 705 for a given number can be analyzed using another process orthread that executes on the mobile device 110. As shown in FIG. 10,various heuristics 1005 may be applied to the RCS availability 905 inorder to estimate RCS capabilities 1010 (and/or non-RCS capabilities insome cases) in a broader sense. In an illustrative example, the RCSavailability of a number over time can be analyzed to generatehistorical data. The analysis can thus enable some prediction to be madeas to the likelihood that a contact has video capability at any givenpoint in time. For example, the historical data could tend to show thata contact does not have video capabilities at certain times of nightperhaps because the mobile device is shut off or the user does not wishto be disturbed. In another example, the analysis may indicate a highprobability that a particular mobile device has video capability basedon its past history of RCS availability.

The present on demand model for efficiently retrieving video capabilitymay be implemented using a tiered approach, as shown in FIG. 11, inwhich different options may be utilized depending on the particularneeds of a given implementation. These include a minimal option 1105, abasic caching option 1110, a caching with timestamp option 1115, aretrieval in lists option 1120, and a retrieval in lists with APIs(Application Programming Interfaces) option 1125. Each successive optionbuilds on the others which advantageously enables reduced developmenttime for deployments using the present on demand model since softwarecode in the minimal option is reused in substantial part in the basiccaching option, which is reused in the caching with timestamp option,and so on. It is noted that contact lists are commonly supported in manymobile devices, hence it can be expected that the retrieval in listsoption 1120 and the retrieval in lists with APIs option 1125 will beutilized in many typical deployments. The other options (i.e., minimal,basic caching, and caching with timestamp) are typically more suited todeployments in which the UI on a mobile device shows individual contactcards and does not show contact lists.

FIG. 12 is a flowchart that depicts an illustrative method 1200 forimplementing the minimal option 1105 (FIG. 11). Unless specificallystated, the methods or steps shown in the flowcharts contained hereinand described in the accompanying text are not constrained to aparticular order or sequence. In addition, some of the methods or stepsthereof can occur or be performed concurrently and not all the methodsor steps have to be performed in a given implementation depending on therequirements of such implementation and some methods or steps may beoptionally utilized.

In step 1210, a mobile device user 105 (FIG. 1) opens a contact cardthat is stored on the mobile device 110. In step 1215, the backgroundprocess 715 (FIG. 7) retrieves status for the number in the contact cardfrom the service 155 (FIG. 1). While waiting for the status retrieval tofinish, a temporary UI is shown on the device's display screen in step1220. The temporary UI can either show that the status for the contactis currently unknown or that the status is false (i.e., that no videocapability is presently supported for the contact). The UI is thenupdated with current status when the status retrieval from the serviceis completed in step 1225.

FIG. 13 is a flowchart that depicts an illustrative method 1300 forimplementing the basic caching option 1110 (FIG. 11). Steps 1310 and1315 are the same as steps 1210 and 1215 in method 1200 shown in FIG. 12and described in the accompanying text. In step 1320, while waiting forthe status retrieval to finish, a temporary UI is shown using the mostrecently cached status (for the initial condition in which status is notcached, the UI can show unknown or false status as in the minimaloption). The UI is then updated with current status when the statusretrieval from the service is completed in step 1325 and the retrievedstatus is cached in memory in the mobile device 110 in step 1330 forfuture use (i.e., subsequent instances of access to the contact card bythe user 105).

FIG. 14 is a flowchart that depicts an illustrative method 1400 forimplementing the caching with timestamp option 1115 (FIG. 11). Steps1410 through 1430 are the same as steps 1310 through 1330 in method 1300shown in FIG. 13 and described in the accompanying text. In step 1435, atimestamp for the retrieved status is cached by the background process715 (FIG. 7) on the mobile device 110. As described above, the timestampcan be generated by the service 155 and included as part of the status705 or be generated by the background process 715 when the status isreceived, or by another process, thread, or application that executes onthe mobile device.

The cached timestamp may be utilized to enable the status toautomatically expire after some predetermined time interval. The lengthof the time interval can vary according to the needs of a particularimplementation. Generally, a longer time interval prior to statusexpiration means that a smaller number of retrievals are utilized whichcan preserve resources, but there is a risk with longer intervals thatthe status becomes stale and does not accurately reflect the videocapabilities of a contact. In step 1440, status retrieval attempts maybe throttled using the timestamp so that status retrieval for a contactwill not be attempted so long as the status of the contact of interestremains valid (i.e., unexpired).

FIG. 15 is a flowchart that depicts an illustrative method 1500 forimplementing the retrieval in lists option 1120 (FIG. 11). In step 1510,the mobile device user 105 invokes an action that causes a contact listto be generated and shown on the UI supported on the mobile device'sdisplay 505 (FIG. 5). Any of a variety of actions can typically causethe mobile device to show contacts in a list format on the display. Forexample, the user may invoke a contacts application on the mobile devicein order to browse all stored contacts, in which case the applicationwill often show groups of contacts on each of several screens. The usermay navigate from screen to screen to browse the contacts by scrollingor using other actions.

Another example includes the user invoking a dialer application in orderto place a voice call. FIG. 16 shows a screenshot of an illustrative UI1600 exposed by a dialer application that executes on a mobile device110. In this example, the dialer application provides a virtual keypad1605 on the lower portion of the display (which is configured as atouchscreen display here). The dialer application in this example isconfigured as a predictive or “smart” dialer that is designed to savekey presses and reduce the amount of user input needed to place thecall. The UI includes a digit display 1610 towards the top of thedisplay where, in this example, the user 105 has entered the digit “4.”The predictive dialer has been configured to interpret this digit “4”using its assigned text representation of the letters “G,” “H,” and “I.”Accordingly, the predictive dialer shows a list 1615 of contacts havingeither first or last names that start with one of these letters.

This particular UI 1600 is designed to show four contacts at a timeabove the keypad 1605 and below the digit display 1610 (other UI designscan vary in the number of contacts that are shown at the same time). Thefour contacts thus constitute one screen of the full list of contactsthat meet the criteria of first or last names starting with the letters“G,” “H,” or “I.” As it is possible that the list of contacts meetingsuch criteria has more than four members, additional contacts maytypically be viewed on the UI by scrolling or using other actions inorder to reveal additional screens that are shown on the display. In asimilar manner to that shown in FIG. 5, video glyphs (representativelyindicated by reference numeral 1620) are displayed on the UI next tocontacts that are associated with devices that have video capabilitybased on cached or retrieved status.

FIG. 17 depicts another UI 1700 that shows a contact list 1715 that isgenerated in response to the user 105 engaging with a predictive dialerapplication on the mobile device 110. In this example, the user haspressed a sequence of digits using the keypad 1705 that are shown as astring in the digit display 1710. Contacts having phone numbers thatinclude the digit string as entered are displayed in the list 1715.Similarly to the above example, any additional contacts having phonenumbers that meet these criteria may be accessed on other screens. Inaddition, video glyphs (representatively indicated by reference numeral1720) are shown next to contacts having mobile devices that supportvideo capability based on cached or retrieved status.

Returning to FIG. 15, after the mobile device user invokes an actionthat causes a contact list to be shown, such as using the smart dialeras shown in FIGS. 16 and 17, the background process in step 1515 makes abatch request to retrieve status from the service 155 for each of thecontacts currently being displayed. The background process in this step1515 will also retrieve status for additional screens of contacts in thelist to pre-fetch data that the user may wish to see, for example byscrolling the UI. The criteria that may be applied when retrievingadditional status are described below in the text accompanying FIG. 20.

In step 1520, a temporary UI is shown on the mobile device's displaywhile waiting for the status retrieval to finish using the most recentlycached status for the contacts in the list that is shown. Accordingly,the background process 715 (FIG. 7) will typically prioritize retrievalof the status for contacts being currently shown over the retrieval ofstatus for the additional screens. The UI is updated with current statuswhen the status retrieval from the service is completed in step 1525 andthe retrieved status is cached in memory in the mobile device 110 instep 1530 for future use.

In step 1535, a timestamp for the retrieved status for each contact iscached by the background process 715 on the mobile device 110. Thecached timestamp may be utilized to enable the status to automaticallyexpire after some predetermined time interval. Contact cards and contactlists can have different expiration intervals. For example, status for acontact card may expire in one minute while status for a contact listmay expire in 15 minutes (these time intervals are intended to beillustrative and other expiration intervals can be used to meet theneeds of a particular implementation). In step 1540, status retrievalattempts may be throttled using the timestamp so that status retrievalfor a contact will not be attempted so long as the status of the contactcard or contact list of interest remains valid (i.e., unexpired).

The UIs 1600 and 1700 shown in FIGS. 16 and 17 are typically arranged toenable the user 105 to select a contact from a contact list (e.g.,contact lists 1615 and 1715) and then place the call. For example, bytouching the picture or name of the contact to select it, the user mayplace the call by touching the call button at the bottom of the keypad.Alternatively, the user may select a contact and place a call using avoice command or non-touch gesture in some implementations.

As shown in the UI 1800 depicted in FIG. 18, the user 105 has placed acall to the contact named “Thomas Howard.” The UI is arranged in thisexample to show the picture of the contact in enlarged view, thecontact's phone number, the call duration in minutes and seconds, and avideo glyph 1820 to indicate that the contact has video capability basedon the retrieved status. The UI 1800 also exposes various call controlfeatures that may be invoked using buttons 1805 that are includedtowards the bottom of the UI. In alternative implementations, callcontrol features can be invoked using voice command or non-touchgestures. In this illustrative example, a video button 1825 is includedin the UI that can make the call a video call when invoked. Bycomparison, in the UI 1900 shown for the contact “Peter Yanovich” inFIG. 19, there is no video glyph displayed because the status for thecontact indicates no video capability is currently supported. Inaddition, the video button 1925 is grayed out to indicate that thecapability is unavailable (in alternative implementations, the button1925 may not be displayed at all among the call control buttons).

FIG. 20 shows an illustrative taxonomy for criteria 2000 that may beapplied when retrieving status for additional screens of contacts in acontact list, as discussed above. In some implementations, the visualproximity of other contacts to the currently displayed contacts in thelist is utilized, as indicated by reference numeral 2005. In this case,the status for contacts that are close to the currently displayedcontacts on the UI is retrieved. Thus, for example, in a UI which isdesigned for scrolling up and down to show contacts in alphabeticalorder, status for contacts in the one or more screens immediately aboveand below the currently displayed screen could be retrieved as it can bereasonably expected that the user may wish to scroll the UI to viewthose additional contacts.

The relationship proximity of contacts (indicated by reference numeral2010) may also be used as criteria when retrieving status for contactsin additional screens. Here, the additional contacts are those that areproximate in relationship to the currently displayed contacts and caninclude special contacts 2015, frequently used contacts 2020, contactscalled before or most recently called 2025, and contacts having knowncapabilities 2030. In some implementations an individual criterion maybe used, or a mix of criteria can also be used, and not all criteriashown in FIG. 20 need to be used in every implementation.

Special contacts can include those that the user has designated orcategorized on the mobile device as having special importance orbelonging to a particular group. For example, such categories couldinclude friends and family, colleagues, inner circle, favorites, and thelike. So if one or more contacts shown in the currently displayed listhave special importance or are members of a particular group, thebackground process 715 can pre-fetch status for other contacts that alsohave such properties. Similarly, if one or more contacts in thecurrently displayed list are among the user's most frequently used oraccessed contacts, then other such contacts that are also frequentlyused or accessed can be pre-fetched for display in additional screens.What constitutes frequently used in this particular context can vary byimplementation. If the one or more contacts in the currently displayedlist have been called before and/or have been among the most recentlycalled contacts, then other contacts having similar properties can bepre-fetched for display in additional screens. What constitutes mostrecently called in this particular context can vary by implementation.If one or more contacts having known capabilities (e.g., the contact isknown to have video capability through application of heuristics to thestatus data as described above) are shown in the currently displayedlist, the other contacts having similar or the same capabilities can bepre-fetched for display in additional screens.

The additional screen retrieval criteria 2000 can further includelocation 2035 and time 2040 and also take into account various otherassociative properties of contacts or filtering 2045. The locationcriteria 2035 can take into account a location of mobile deviceassociated with a contact so that, for example, status can bepre-fetched for other contacts that are in the same city as a contactthat is currently displayed in a list (where the location boundaries inthis context can vary by implementation). The time criteria 2040 cantake into account the current time for a mobile device associated with auser. So, for example, status can be pre-fetched for other contacts thatshare the same time zone as a contact that is currently displayed in alist (where the time boundaries in this context can vary byimplementation).

As noted above the additional screen retrieval criteria 2000 can be usedindividually or in combination. Thus, status can be pre-fetched only forcontacts that meet several criteria. For example, status can bepre-fetched for contacts that are members of the user's frequentlycalled numbers and are located in the same city as a contact that iscurrently shown in a list that is displayed on a mobile device.

The retrieval in lists with APIs option 1125 discussed above inconjunction with FIG. 11 uses a method that is substantially similar tothat described for method 1500 above and shown in FIG. 15. Thedifference is that the retrieval in lists with APIs option uses a methodthat interfaces with several public APIs. In an illustrative example,the public APIs are exposed by the service 155 as shown in FIGS. 21 and22. In FIG. 21, a first of the public APIs 2105 is configured to respondto a request 2110 with status 2115 for one number/contact at a time.When status is received at the mobile device 110, it may triggeradditional requests which can be delayed in some cases in order to placethem closer in time in a pseudo-batch manner so that radioinitialization overhead costs are shared among multiple requests.

In FIG. 22, a second of the public APIs 2205 is configured to respond tobatched retrieval requests 2210 with batched status 2215 for multiplecontacts/numbers at a time. A notification 2220 is also sent by theservice 155 when the status update to the mobile device 110 is complete.In typical implementations in which contact lists are shown on the UI ofthe mobile device 110, it is anticipated that the second public API 2205would be utilized by the background process 715 to retrieve statusupdates due to resource savings that are enabled through the batchedprocessing. When a single contact card is accessed, then the firstpublic API 2105 could be used without incurring a resource penalty.

FIG. 23 is a simplified block diagram of an illustrative computer system2300 such as a personal computer (PC), client machine, or server withwhich the present video capability retrieval may be implemented in someapplications. Computer system 2300 includes a processor 2305, a systemmemory 2311, and a system bus 2314 that couples various systemcomponents including the system memory 2311 to the processor 2305. Thesystem bus 2314 may be any of several types of bus structures includinga memory bus or memory controller, a peripheral bus, or a local bususing any of a variety of bus architectures. The system memory 2311includes read only memory (ROM) 2317 and random access memory (RAM)2321. A basic input/output system (BIOS) 2325, containing the basicroutines that help to transfer information between elements within thecomputer system 2300, such as during startup, is stored in ROM 2317. Thecomputer system 2300 may further include a hard disk drive 2328 forreading from and writing to an internally disposed hard disk (notshown), a magnetic disk drive 2330 for reading from or writing to aremovable magnetic disk 2333 (e.g., a floppy disk), and an optical diskdrive 2338 for reading from or writing to a removable optical disk 2343such as a CD (compact disc), DVD (digital versatile disc), or otheroptical media. The hard disk drive 2328, magnetic disk drive 2330, andoptical disk drive 2338 are connected to the system bus 2314 by a harddisk drive interface 2346, a magnetic disk drive interface 2349, and anoptical drive interface 2352, respectively. The drives and theirassociated computer-readable storage media provide non-volatile storageof computer-readable instructions, data structures, program modules, andother data for the computer system 2300. Although this illustrativeexample includes a hard disk, a removable magnetic disk 2333, and aremovable optical disk 2343, other types of computer-readable storagemedia which can store data that is accessible by a computer such asmagnetic cassettes, Flash memory cards, digital video disks, datacartridges, random access memories (RAMs), read only memories (ROMs),and the like may also be used in some applications of the present videocapability retrieval. In addition, as used herein, the termcomputer-readable storage media includes one or more instances of amedia type (e.g., one or more magnetic disks, one or more CDs, etc.).For purposes of this specification and the claims, the phrase“computer-readable storage media” and variations thereof, does notinclude waves, signals, and/or other transitory and/or intangiblecommunication media.

A number of program modules may be stored on the hard disk 2328,magnetic disk 2333, optical disk 2343, ROM 2317, or RAM 2321, includingan operating system 2355, one or more application programs 2357, otherprogram modules 2360, and program data 2363. A user may enter commandsand information into the computer system 2300 through input devices suchas a keyboard 2366 and pointing device 2368 such as a mouse. Other inputdevices (not shown) may include a microphone, joystick, game pad,satellite dish, scanner, trackball, touchpad, touch screen,touch-sensitive device, voice-command module or device, user motion oruser gesture capture device, or the like. These and other input devicesare often connected to the processor 2305 through a serial portinterface 2371 that is coupled to the system bus 2314, but may beconnected by other interfaces, such as a parallel port, game port, oruniversal serial bus (USB). A monitor 2373 or other type of displaydevice is also connected to the system bus 2314 via an interface, suchas a video adapter 2375. In addition to the monitor 2373, personalcomputers typically include other peripheral output devices (not shown),such as speakers and printers. The illustrative example shown in FIG. 23also includes a host adapter 2378, a Small Computer System Interface(SCSI) bus 2383, and an external storage device 2376 connected to theSCSI bus 2383.

The computer system 2300 is operable in a networked environment usinglogical connections to one or more remote computers, such as a remotecomputer 2388. The remote computer 2388 may be selected as anotherpersonal computer, a server, a router, a network PC, a peer device, orother common network node, and typically includes many or all of theelements described above relative to the computer system 2300, althoughonly a single representative remote memory/storage device 2390 is shownin FIG. 23. The logical connections depicted in FIG. 23 include a localarea network (LAN) 2393 and a wide area network (WAN) 2395. Suchnetworking environments are often deployed, for example, in offices,enterprise-wide computer networks, intranets, and the Internet.

When used in a LAN networking environment, the computer system 2300 isconnected to the local area network 2393 through a network interface oradapter 2396. When used in a WAN networking environment, the computersystem 2300 typically includes a broadband modem 2398, network gateway,or other means for establishing communications over the wide areanetwork 2395, such as the Internet. The broadband modem 2398, which maybe internal or external, is connected to the system bus 2314 via aserial port interface 2371. In a networked environment, program modulesrelated to the computer system 2300, or portions thereof, may be storedin the remote memory storage device 2390. It is noted that the networkconnections shown in FIG. 23 are illustrative and other means ofestablishing a communications link between the computers may be useddepending on the specific requirements of an application of the presentvideo capability retrieval.

FIG. 24 shows an illustrative architecture 2400 for a device capable ofexecuting the various components described herein for providing thepresent video capability retrieval. Thus, the architecture 2400illustrated in FIG. 24 shows an architecture that may be adapted for aserver computer, mobile phone, a PDA (personal digital assistant), asmartphone, a desktop computer, a netbook computer, a tablet computer,GPS (Global Positioning System) device, gaming console, and/or a laptopcomputer. The architecture 2400 may be utilized to execute any aspect ofthe components presented herein.

The architecture 2400 illustrated in FIG. 24 includes a CPU 2402, asystem memory 2404, including a RAM 2406 and a ROM 2408, and a systembus 2410 that couples the memory 2404 to the CPU 2402. A basicinput/output system containing the basic routines that help to transferinformation between elements within the architecture 2400, such asduring startup, is stored in the ROM 2408. The architecture 2400 furtherincludes a mass storage device 2412 for storing software code or othercomputer-executed code that is utilized to implement applications, thefile system, and the operating system.

The mass storage device 2412 is connected to the CPU 2402 through a massstorage controller (not shown) connected to the bus 2410. The massstorage device 2412 and its associated computer-readable storage mediaprovide non-volatile storage for the architecture 2400.

Although the description of computer-readable storage media containedherein refers to a mass storage device, such as a hard disk or CD-ROMdrive, it should be appreciated by those skilled in the art thatcomputer-readable storage media can be any available storage media thatcan be accessed by the architecture 2400.

By way of example, and not limitation, computer-readable storage mediamay include volatile and non-volatile, removable and non-removable mediaimplemented in any method or technology for storage of information suchas computer-readable instructions, data structures, program modules, orother data. For example, computer-readable media includes, but is notlimited to, RAM, ROM, EPROM (erasable programmable read only memory),EEPROM (electrically erasable programmable read only memory), Flashmemory or other solid state memory technology, CD-ROM, DVDs, HD-DVD(High Definition DVD), Blu-ray, or other optical storage, magneticcassettes, magnetic tape, magnetic disk storage or other magneticstorage devices, or any other medium which can be used to store thedesired information and which can be accessed by the architecture 2400.

According to various embodiments, the architecture 2400 may operate in anetworked environment using logical connections to remote computersthrough a network. The architecture 2400 may connect to the networkthrough a network interface unit 2416 connected to the bus 2410. Itshould be appreciated that the network interface unit 2416 also may beutilized to connect to other types of networks and remote computersystems. The architecture 2400 also may include an input/outputcontroller 2418 for receiving and processing input from a number ofother devices, including a keyboard, mouse, or electronic stylus (notshown in FIG. 24). Similarly, the input/output controller 2418 mayprovide output to a display screen, a printer, or other type of outputdevice (also not shown in FIG. 24).

It should be appreciated that the software components described hereinmay, when loaded into the CPU 2402 and executed, transform the CPU 2402and the overall architecture 2400 from a general-purpose computingsystem into a special-purpose computing system customized to facilitatethe functionality presented herein. The CPU 2402 may be constructed fromany number of transistors or other discrete circuit elements, which mayindividually or collectively assume any number of states. Morespecifically, the CPU 2402 may operate as a finite-state machine, inresponse to executable instructions contained within the softwaremodules disclosed herein. These computer-executable instructions maytransform the CPU 2402 by specifying how the CPU 2402 transitionsbetween states, thereby transforming the transistors or other discretehardware elements constituting the CPU 2402.

Encoding the software modules presented herein also may transform thephysical structure of the computer-readable storage media presentedherein. The specific transformation of physical structure may depend onvarious factors, in different implementations of this description.Examples of such factors may include, but are not limited to, thetechnology used to implement the computer-readable storage media,whether the computer-readable storage media is characterized as primaryor secondary storage, and the like. For example, if thecomputer-readable storage media is implemented as semiconductor-basedmemory, the software disclosed herein may be encoded on thecomputer-readable storage media by transforming the physical state ofthe semiconductor memory. For example, the software may transform thestate of transistors, capacitors, or other discrete circuit elementsconstituting the semiconductor memory. The software also may transformthe physical state of such components in order to store data thereupon.

As another example, the computer-readable storage media disclosed hereinmay be implemented using magnetic or optical technology. In suchimplementations, the software presented herein may transform thephysical state of magnetic or optical media, when the software isencoded therein. These transformations may include altering the magneticcharacteristics of particular locations within given magnetic media.These transformations also may include altering the physical features orcharacteristics of particular locations within given optical media tochange the optical characteristics of those locations. Othertransformations of physical media are possible without departing fromthe scope and spirit of the present description, with the foregoingexamples provided only to facilitate this discussion.

In light of the above, it should be appreciated that many types ofphysical transformations take place in the architecture 2400 in order tostore and execute the software components presented herein. It alsoshould be appreciated that the architecture 2400 may include other typesof computing devices, including handheld computers, embedded computersystems, smartphones, PDAs, and other types of computing devices knownto those skilled in the art. It is also contemplated that thearchitecture 2400 may not include all of the components shown in FIG.24, may include other components that are not explicitly shown in FIG.24, or may utilize an architecture completely different from that shownin FIG. 24.

FIG. 25 is a functional block diagram of an illustrative mobile device110 such as a mobile phone or smartphone including a variety of optionalhardware and software components, shown generally at 2502. Any component2502 in the mobile device can communicate with any other component,although, for ease of illustration, not all connections are shown. Themobile device can be any of a variety of computing devices (e.g., cellphone, smartphone, handheld computer, Personal Digital Assistant (PDA),etc.) and can allow wireless two-way communications with one or moremobile communication networks 2504, such as a cellular or satellitenetwork.

The illustrated mobile device 110 can include a controller or processor2510 (e.g., signal processor, microprocessor, microcontroller, ASIC(Application Specific Integrated Circuit), or other control andprocessing logic circuitry) for performing such tasks as signal coding,data processing, input/output processing, power control, and/or otherfunctions. An operating system 2512 can control the allocation and usageof the components 2502, including power states, above-lock states, andbelow-lock states, and provides support for one or more applicationprograms 2514. The application programs can include common mobilecomputing applications (e.g., image-capture applications, emailapplications, calendars, contact managers, web browsers, messagingapplications), or any other computing application.

The illustrated mobile device 110 can include memory 2520. Memory 2520can include non-removable memory 2522 and/or removable memory 2524. Thenon-removable memory 2522 can include RAM, ROM, Flash memory, a harddisk, or other well-known memory storage technologies. The removablememory 2524 can include Flash memory or a Subscriber Identity Module(SIM) card, which is well known in GSM (Global System for Mobilecommunications) systems, or other well-known memory storagetechnologies, such as “smart cards.” The memory 2520 can be used forstoring data and/or code for running the operating system 2512 and theapplication programs 2514. Example data can include web pages, text,images, sound files, video data, or other data sets to be sent to and/orreceived from one or more network servers or other devices via one ormore wired or wireless networks.

The memory 2520 may also be arranged as, or include, one or morecomputer-readable storage media implemented in any method or technologyfor storage of information such as computer-readable instructions, datastructures, program modules or other data. For example,computer-readable media includes, but is not limited to, RAM, ROM,EPROM, EEPROM, Flash memory or other solid state memory technology,CD-ROM (compact-disc ROM), DVD, (Digital Versatile Disc) HD-DVD (HighDefinition DVD), Blu-ray, or other optical storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can be accessed by the mobile device 110.

The memory 2520 can be used to store a subscriber identifier, such as anInternational Mobile Subscriber Identity (IMSI), and an equipmentidentifier, such as an International Mobile Equipment Identifier (IMEI).Such identifiers can be transmitted to a network server to identifyusers and equipment. The mobile device 110 can support one or more inputdevices 2530; such as a touch screen 2532; microphone 2534 forimplementation of voice input for voice recognition, voice commands andthe like; camera 2536; physical keyboard 2538; trackball 2540; and/orproximity sensor 2542; and one or more output devices 2550, such as aspeaker 2552 and one or more displays 2554. Other input devices (notshown) using gesture recognition may also be utilized in some cases.Other possible output devices (not shown) can include piezoelectric orhaptic output devices. Some devices can serve more than one input/outputfunction. For example, touchscreen 2532 and display 2554 can be combinedinto a single input/output device.

A wireless modem 2560 can be coupled to an antenna (not shown) and cansupport two-way communications between the processor 2510 and externaldevices, as is well understood in the art. The modem 2560 is showngenerically and can include a cellular modem for communicating with themobile communication network 2504 and/or other radio-based modems (e.g.,Bluetooth 2564 or Wi-Fi 2562). The wireless modem 2560 is typicallyconfigured for communication with one or more cellular networks, such asa GSM network for data and voice communications within a single cellularnetwork, between cellular networks, or between the mobile device and apublic switched telephone network (PSTN).

The mobile device can further include at least one input/output port2580, a power supply 2582, a satellite navigation system receiver 2584,such as a Global Positioning System (GPS) receiver, an accelerometer2586, a gyroscope (not shown), and/or a physical connector 2590, whichcan be a USB port, IEEE 1394 (FireWire) port, and/or an RS-232 port. Theillustrated components 2502 are not required or all-inclusive, as anycomponent can be deleted and other components can be added.

Based on the foregoing, it should be appreciated that technologies forvideo capability retrieval have been disclosed herein. Although thesubject matter presented herein has been described in language specificto computer structural features, methodological and transformative acts,specific computing machinery, and computer-readable storage media, it isto be understood that the invention defined in the appended claims isnot necessarily limited to the specific features, acts, or mediadescribed herein. Rather, the specific features, acts, and mediums aredisclosed as example forms of implementing the claims.

The subject matter described above is provided by way of illustrationonly and should not be construed as limiting. Various modifications andchanges may be made to the subject matter described herein withoutfollowing the example embodiments and applications illustrated anddescribed, and without departing from the true spirit and scope of thepresent invention, which is set forth in the following claims.

1-20. (canceled)
 21. A method performed on a mobile device with a userinterface (UI) and having access to a mobile broadband network,comprising: receiving a first input from a user of the mobile device forinvoking display of a contact card or a contact list on the UI;responsively to the first input, sending a first request to a remoteservice for current status of capabilities of devices respectivelyassociated with each of the displayed contacts, the status describingcapabilities of the devices to implement features or services supportedby the mobile broadband network; caching, at the mobile device, thecurrent status received from the remote service responsively to thefirst request; receiving a second input from the user for invokingdisplay of the contact card or the contact list on the UI; responsivelyto the second input, sending a second request to a remote service forcurrent status of capabilities of devices respectively associated witheach of the displayed contacts; and while waiting for the service torespond to the second request, displaying a temporary UI to the user onthe mobile device, the temporary UI showing the invoked contact card orcontact list including the cached status for each of the displayedcontacts.
 22. The method of claim 21 further including receiving thecurrent status responsively to the second request from the remoteservice and updating the UI with the received current status for one ormore of the displayed contacts.
 23. The method of claim 21 furtherincluding receiving the current status for a contact from the remoteservice, applying a timestamp to the received status, and throttlingrequests for status to the remote service using the timestamp.
 24. Themethod of claim 23 in which the timestamp defines a start of apredetermined time interval and the throttling comprises limitingrequests to the remote service for current status during thepredetermined time interval to a maximum of one request for currentstatus.
 25. The method of claim 23 in which the timestamp is generatedby the remote service.
 26. The method of claim 23 in which the timestampis generated by the mobile device.
 27. The method of claim 21 in whichthe first or second request for current status includes batched requestsfor status of capabilities for a plurality of devices respectivelyassociated with each of the displayed contacts.
 28. A mobile devicehaving connectivity to a mobile operator network, comprising: one ormore processors; a display that supports a user interface (UI) forconveying information to a user of the mobile device; and one or morememory devices storing computer-readable instructions which, whenexecuted by the one or more processors, cause the mobile device to:receive an input from the user that invokes display of a list ofcontacts on the UI, show the list of contacts on a displayed screen onthe UI responsively to the received input, the displayed screen showinga most recently cached status for each of the listed contacts, send arequest to a remote service for current status of capabilities ofdevices respectively associated with each of the listed contactsdisplayed on the displayed screen, update the displayed screen with thecurrent status for each of the listed contacts displayed on thedisplayed screen when the current status is received from the remoteservice, pre-fetch status from the remote service for contacts inadditional screens that are displayable on the UI, the contacts in theadditional screens having a contextual relationship to the contactsshown in a current screen, display one or more additional screens ofcontacts including the pre-fetched status responsively to user input toview additional screens; and applying a timestamp to the receivedcurrent status, and throttling requests for current status to the remoteservice using the timestamp, wherein the timestamp is utilized to enablea current status for a contact to automatically expire at the end of apredetermined time interval, and wherein no more than one request ismade to the remote service for current status during the predeterminedtime interval.
 29. The mobile device of claim 28 in which the mobileoperator network comprises a mobile broadband network.
 30. The mobiledevice of claim 28 in which the user input is associated withutilization of a dialer application.
 31. The mobile device of claim 28in which the capabilities include at least availability of a device torender streaming video transmitted over an LTE (Long Term Evolution)mobile broadband network.
 32. The mobile device of claim 28 in which thecontextual relationship is one of visual proximity, relationshipproximity, location, time, or associative property.
 33. The mobiledevice of claim 32 in which the relationship proximity includes contactsin the current screen and contacts in the additional screens sharingmembership in one of special contacts, frequently used contacts, mostrecently called contacts, contacts called before, or contacts havingknown capabilities.
 34. The mobile device of claim 28 further includingapplying one or more heuristics to data included in the received statusto make inferences as to capabilities of a device to which the receivedstatus is associated.
 35. A method for providing a service that returnscapabilities status in response to a request from a mobile device,comprising: receiving one or more requests for current status made froma mobile device having connectivity to a mobile broadband network,wherein status specifies capabilities of one or more devices which areassociated with a single contact shown in a contact card on a userinterface (UI) supported by the mobile device or which are respectivelyassociated with a plurality of contacts shown in a list on the UI; andin response to the requests for current status, sending the currentstatus to the mobile device, wherein the request for current status isthrottled at the mobile device so that no more than one request forcurrent status is made to the service during a time interval having avariable length, the time interval being relatively shorter for currentstatus requests for a single contact shown in a contact card on the UI,and the time interval being relatively longer for current statusrequests for a plurality of contacts shown in a list on the UI.
 36. Themethod of claim 35 in which the service is exposed by a network elementdisposed in the mobile broadband network.
 37. The method of claim 35 inwhich capabilities of the device include capabilities to implementfeatures or services supported by the mobile broadband network, thefeatures or services being related to video consumption or videorendering.
 38. The method of claim 35 further including exposing anapplication programming interface configured for fulfilling statusrequests for a single contact per request.
 39. The method of claim 35further including exposing an application programming interfaceconfigured for fulfilling status requests on a batched request basis.40. The method of claim 39 further including sending a notification whenstatus responsive to the batched request is fulfilled.